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Abstract 


This document describes how Ethernet Shortest Path Bridging MAC mode 
(SPBM) can be combined with Ethernet VPN (EVPN) to interwork with 
Provider Backbone Bridging Provider Edges (PBB PEs) as described in 
the PBB-EVPN solution (RFC 7623). This is achieved via operational 
isolation of each Ethernet network attached to an EVPN core while 
supporting full interworking between the different variations of 
Ethernet networks. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7734. 


Allan, et al. Standards Track [Page 1] 


REC 7734 SPBM Support over EVPN January 2016 


Copyright Notice 


Copyright (c) 2016 IETF Trust and the persons identified as the 
document authors. All rights reserved. 
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1. Introduction 


This document describes how Ethernet Shortest Path Bridging MAC mode 
(SPBM) [IEEE.802.10] along with Provider Backbone Bridging Provider 
Edges (PBB PEs) and Provider Backbone Bridged Networks (PBBNs) can be 
supported by Ethernet VPNs (EVPNs) such that each SPBM island is 
operationally isolated while providing full L2 connectivity between 
the different types of PBBNs where desired. Each SPBM island uses 
its own control-plane instance and multipathing design, be it 
multiple equal-cost tree sets or multiple spanning trees. 


The intention is to permit past, current, and emerging future 
versions of Ethernet to be seamlessly interconnected to permit large- 
scale, geographically diverse numbers of Ethernet end systems to be 
fully supported with EVPN as the unifying system. 


1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. Conventions Used in This Document 
2.1. Terminology 


Terms used in this document are used as specified in IEEE 
802.10-2014, which incorporates earlier IEEE 802.1 projects. 


BEB: Backbone Edge Bridge 

BGP: Border Gateway Protocol 

B-MAC: Backbone MAC 

B-VID: Backbone VLAN ID 

CE: Customer Edge 

DA: Destination Address 

DF: Designated Forwarder 

ESI: Ethernet Segment Identifier 

EVPN: Ethernet VPN 

IB-BEB: A BEB that has both an I-component (customer-layer VLAN-aware 
bridge) and a B-component (backbone-layer VLAN-aware bridge) 

ISIS-SPB: IS-IS as extended for SPB 

I-SID: Backbone Service Instance Identifier 

NLRI: Network Layer Reachability Information 

PBB: Provider Backbone Bridging as in Clauses 25 and 26 of 

[IEEE.802.10] 

PBBN: Provider Backbone Bridged Network 

PBB PE: Co-located BEB and EVPN PE 

PE: Provider Edge 
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SPB: Shortest Path Bridging 

SPBM: Shortest Path Bridging MAC mode as in Clauses 27 and 28 of 
[IEEE.802.10] 

SPBM-PE: Co-located SPBM<->EVPN interworking function and EVPN PE 


3. Solution Overview 


The EVPN solution for SPBM, as specified in [IEEE.802.10], 
incorporates control-plane interworking in the PE to map ISIS-SPB 
[RFC6329] information elements into the EVPN Next Layer Reachability 
Information (NLRI) and vice versa. This requires each PE to act both 
as an EVPN BGP speaker and as an ISIS-SPB edge node. Associated with 
this are procedures for configuring the forwarding operations of the 
PE such that an arbitrary number of EVPN-attached SPBM islands can be 
interconnected without any topological or multipathing dependencies. 
This model also permits PBB PEs as defined in [RFC7623] to seamlessly 
communicate with the SPBM islands. 


4+-------------- + +----+ +=--+ 
| | PBB |---|cE2| 
| | [PES | +---+ 
4+----- + 4+----+ 4+----+ 
j j- srm] | | 
|SPBM | |PE1 | | IP/MPLS | 
+---+ |NTWK1| +----+ | Network | 
CA | | 
+ o | + | | 
| |----- SPBM | +----+ 4 => + 
+----- + PE2 | SPBM | |SPBM | +---+ 
+----+ | | |PE5 |---|NTWK2|-|CE3| 
4+-------------- + +----+ 4+----- + +=--+ 


Figure 1: PBB and SPBM EVPN Network 


Figure 1 illustrates the generalized space addressed by this memo. 
SPBM networks may be multihomed onto an IP/MPLS network that 
implements EVPN for the purpose of interconnecting with other SPBM 
networks and/or PBB PEs. The multipathing configuration of each SPBM 
network can be unique as the backbone VLAN ID (B-VID) configuration 
(how multipathing is performed in SPBM) is not propagated across the 
IP/MPLS network implementing EVPN. As with PBB networking, the B-VID 
is local to the SPBM network, so in SPBM a B-MAC associated with the 
B-VID is advertised with the supported I-SIDs at the PBB gateway. 


Each EVPN is identified by a route target. I-SID-based load- 
balancing as specified in [RFC7623] allows multiple gateways per 
B-VID (each with different I-SIDs) across the EVPN; it is supported 
by the interworking between PBBNs and SPBM networks. However, SPBM 
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only allows a single active designated forwarder (DF) per B-VID as 
described below. The route target identifies the set of SPBM islands 
and PBB PEs that are allowed to communicate. Each SPBM island is 
administered to have an Ethernet Segment ID (ESI) Label extended 
community associated with it. 


BGP acts as a common repository of the I-Component Service ID (I-SID) 
attachment points for the set of attached PEs / SPBM islands. This 
is in the form of (B-MAC address, I-SID, Tx-Rx-attribute) tuples. 

BGP distributes I-SID information into each SPBM island on the basis 
of locally registered interest. If an SPBM island has no Backbone 
Edge Bridges (BEBs) registering interest in a particular I-SID, 
information about that I-SID from other SPBM islands, PBB PEs, or 
PBBNs MUST NOT be leaked into the local ISIS-SPB routing system. For 
each B-VID in an SPBM island, a single SPBM-PE MUST be elected the DF 
for the B-VID. An SPBM-PE can be a DF for more than one B-VID. This 
is described further in Section 4.2. The SPBM-PE originates IS-IS 
advertisements as if it were an IB-BEB that proxies for the other 
SPBM islands and PBB PEs in the EVPN defined by the route target, but 
the PE typically will not actually host any I-components. 


An SPBM-PE that is a DF for a B-VID MUST strip the B-VID tag 
information from frames relayed towards the EVPN. The DF MUST also 
insert the appropriate B-VID tag information into frames relayed 
towards the SPBM island on the basis of the local I-SID/B-VID 
bindings advertised in ISIS-SPB. 


4. Elements of Procedure 
A PE MUST implement and perform the following procedures. 
4.1. PE Configuration 
At SPBM island commissioning a PE is configured with: 
1) The route target for the service instance. Where a route target 


is defined as identifying the set of SPBM islands, PBBNs and 
PBB PEs are to be interconnected by the EVPN. 


2) The unique ESI for the SPBM island. Mechanisms for deriving a 
unique ESI for the SPBM island are out of scope. 


The following is configured as part of commissioning an ISIS-SPB 
node: 


1) A Shortest Path Source ID (SPSourceID) used for algorithmic 


construction of multicast addresses. Note this is required for 
SPBM BEB operation independent of the EVPN operation. 
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2) The set of B-VIDs used in the SPBM island and multipathing 
algorithm IDs to use for each. The set of B-VIDs and multipathing 
algorithms used can be different in different domains. Therefore, 
the B-VID is local to an SPBM domain and is removed for frames 
carried over the IP/MPLS network. 


A Type 1 Route Distinguisher for the node can be auto-derived. The 
actual procedure is out of scope for this document. 


4.2. DF Election 


PEs self-appoint themselves for the role of DF for a B-VID for a 
given SPBM island. The procedure used is as per Section 8.5 
(Designated Forwarder Election) of [RFC7432]. 


A PE that assumes the role of DF for a given B-VID is responsible for 
originating specific information into BGP from ISIS-SPB and vice 
versa. A PE that ceases to perform the role of DF for a given B-VID 
is responsible for withdrawing the associated information from BGP 
and ISIS-SPB, respectively. The actual information exchanged is 
outlined in the following sections. 


4.3. Control-Plane Interworking ISIS-SPB to EVPN 


When a PE receives an SPBM service identifier and unicast address 
sub-TLV as part of an ISIS-SPB MT capability TLV, the PE checks if it 
is the DF for the B-VID in the sub-TLV. 


If it is the DF, and there is new or changed information, then a 
MAC/IP advertisement route NLRI is created for each new I-SID in the 
sub-TLV. Changed information that results in modification to 
existing NLRI is processed accordingly. NLRI creation/modification 
will ensure: 


- the Route Distinguisher is set to that of the PE. 

- the ESI is that of the SPBM island. 

- the Ethernet Tag ID contains the I-SID (including the Tx/Rx 
attributes) copied from the SPBM service identifier and unicast 


address sub-TLV. The encoding of I-SID information is as per 
Figure 2. (See [RFC6329] for details on the T bit and R bit.) 


Allan, et al. Standards Track [Page 6] 


REC 7734 SPBM Support over EVPN January 2016 


0 Y 2 3 

(o 1,2 34/05 On 7 2890) V2) 3: 405567 0890. 1:02 34S 6 78 9.0L 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|T|R| Reserved | I-SID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 2: I-SID Encoding in the Ethernet Tag ID Field 


- the MAC address is copied from the SPBM service identifier and 
unicast address sub-TLV 


- a locally assigned MPLS label (which may be common with other NLRI 
originated by the PE and is used to map EVPN traffic to the SPBM 
network) 


Similarly, in the scenario where a PE became elected DF for a B-VID 
in an operating network, the IS-IS database would be processed in 
order to construct the NLRI associated with the new role of the PE. 


If the BGP database has NLRI for the I-SID, and this is the first 
instance of registration of interest in the I-SID from the SPBM 
island, the NLRI for the I-SID is processed to construct an updated 
set of SPBM service identifier and unicast address sub-TLVs to be 
advertised by the PE. 


The ISIS-SPB information is also used to keep current a local table 
indexed by I-SID to indicate the associated B-VID for processing of 
frames received from the EVPN. When an I-SID is associated with more 
than one B-VID, only one entry is allowed in the table. Rules for 
preventing this are out of scope for this memo. 


4.4. Control-Plane Interworking EVPN to ISIS-SPB 


When a PE receives a BGP NLRI that has new information, the PE checks 
if it is the elected DF to communicate this information into ISIS-SPB 
by checking if the I-SID in the Ethernet Tag ID locally maps to the 
B-VID for which it is an elected DF. Note that if no BEBs in the SPB 
island have advertised any interest in the I-SID, it will not be 
associated with any B-VID locally, and therefore will not be of 
interest. If the I-SID is of local interest to the SPBM island and 
the PE is the DF for the B-VID to which the I-SID is locally mapped, 
a SPBM service identifier and unicast address sub-TLV are 
constructed/updated for advertisement into ISIS-SPB. 


The NLRI advertised into ISIS-SPB is also used to locally populate a 
forwarding table indexed by B-MAC + I-SID that points to the label 
stack to impose on the SPBM frame. The bottom label in the stack is 
that obtained from the NLRI. 


Allan, et al. Standards Track [Page 7] 


REC 7734 SPBM Support over EVPN January 2016 


4.5. Data-Plane Interworking SPBM Island or PBB PE to EVPN 


When a PE receives a frame from the SPBM island in a B-VID for which 
it is a DF, it looks up the B-MAC/I-SID information to determine the 
label stack to be added to the frame for forwarding in the EVPN. The 
PE strips the B-VID information from the frame, adds the label 
information to the frame, and forwards the resulting MPLS packet. 


4.6. Data-Plane Interworking EVPN to SPBM Island 


When a PE receives a packet from the EVPN, it can infer the B-VID to 
overwrite in the SPBM frame from the I-SID or by other means (such as 
via the bottom label in the MPLS stack). 


If the frame has a local multicast destination address (DA), it 
overwrites the SPSourceID in the frame with the local SPSourcelD. 


4.7. Data-Plane Interworking EVPN to PBB PE 


A PBB PE actually has no attached PBBN nor concept of B-VID, so no 
frame processing is required. 


A PBB PE is required to accept SPBM-encoded multicast DAs as if they 
were PBB-encoded (i.e., using the Backbone Service Instance Group 
address) for multicast DAs. The only information of interest is that 
it is a multicast frame and the I-SID encoded in the lower 24 bits. 


4.8. Multicast Support 


Within a PBBN domain, Ethernet unicast and multicast end services are 
supported. PBB can tunnel multicast traffic in unicast PBB frames 
when using head-end replication. This is the only form of multicast 
traffic interworking supported by this document. Native PBB 
multicast forwarding over EVPN, PE replication, or optimizing PBB 
multicast across the EVPN is not addressed by this memo. 


5. Other Aspects 
5.1. Transit 
Any PE that does not need to participate in the tandem calculations 


at the B-MAC layer can use the IS-IS overload bit to exclude SPBM 
tandem paths and behave as a pure interworking platform. 
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6. 


Security Considerations 


Security issues associated with incorrect interconnection of customer 
LANs cannot be directly addressed by implementations of this 
document, as it requires misconfiguration in the Shortest Path 


Bridging domains. The identifiers so administered have global 
significance to the larger system. They are relayed transparently by 
EVPN and only policed in the SPBM domains. Therefore, care is 


required in synchronization of identifiers that need to be common for 
inter-domain operation. 


There are only two identifiers unique to this solution provisioned at 
an SPBM-PE at service turn-up: the route target and the ESI. The ESI 
needs to be unique and common to all SPBM-PEs connected to a common 
SPBM network or PBBN, else portions of the overall network will not 
share reachability. (The EVPN will assume that separate networks are 
interconnected by SPBM.) Security issues exist when SPBM domains are 
incorrectly cross-connected together via EVPN; this will result in 
black-holing or incorrect delivery of data with associated privacy 
issues. This error may occur by provisioning the incorrect RT value 
at an SPBM-PE or associating the RT with the wrong interface. This 
error can be avoided by consistency-checking the route target 
provisioning at SPBM-PEs when performing service additions and/or 
changes. 


The behavior that is potentially most destructive to the overall 
system is frequent changes to the DF elections for a given ESI. This 
would occur if the SPBM-PEs continuously had their links go up and 
down in a such a way that the SPBM-PE was being severed from and 
reconnected to either the IP/MPLS network or the attached SPBM 
network. Either of these scenarios would result in significant 
control-plane traffic as DF associated information was advertised and 
withdrawn from both the SPBM and BGP control planes. Dual-homing of 
SPBM-PEs on both networks would minimize the likelihood of this 
scenario occurring. 


The issues associated with securing the BGP control plane 
(independent of this particular memo) are reflected in the Security 
Considerations section of [RFC4761]. 
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